Skip to content

Add target_feature = "gc" for Wasm #150111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
bors merged 1 commit into from
Dec 20, 2025
Merged

Add target_feature = "gc" for Wasm #150111

bors merged 1 commit into from
Dec 20, 2025
+6 −0

Conversation

@daxpedda
Copy link
Contributor

@daxpedda daxpedda commented Dec 17, 2025 •
edited
Loading

This PR adds a new target feature for Wasm targets: GC.

I went ahead and made this insta-stable because it has already passed phase 5 in addition to being implemented and stabilized by all major JS engines.

This doesn't enable the target feature by default!

For context: while this proposal adds a lot of new features to Wasm, they are not accessible through Rust apart from unstable inline ASM. This is largely useful to signal tools to make use of the feature, e.g. wasm-bindgen, where this can be used to make some pretty optimizations.

Companion PR: rust-lang/reference#2114.

r? @alexcrichton

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 17, 2025
@daxpedda daxpedda mentioned this pull request Dec 17, 2025
Draft
@rust-log-analyzer

This comment has been minimized.

Sign in to view
@daxpedda
Copy link
Contributor Author

daxpedda commented Dec 17, 2025

Ah, 'tis unfortunate, will have to wait until the next LLVM version.

@daxpedda daxpedda marked this pull request as draft December 17, 2025 20:41
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 17, 2025
@alexcrichton
Copy link
Member

alexcrichton commented Dec 19, 2025

Looks good to me, thanks! You can update this function to skip the feature on unsupported LLVM versions. Do you have a use case in mind for the insta-stable-ness? I would expect that the GC configuration for wasm-bindgen would be out-of-band rather than via a compiler configuration (e.g. an extra flag to wasm-bindgen itself)

@daxpedda
Copy link
Contributor Author

daxpedda commented Dec 19, 2025 •
edited
Loading

Do you have a use case in mind for the insta-stable-ness? I would expect that the GC configuration for wasm-bindgen would be out-of-band rather than via a compiler configuration (e.g. an extra flag to wasm-bindgen itself)

wasm-bindgen has shifted to removing extra CLI configurations in favor of automatic detection, e.g. reference types, multivalue and other proposals. So instead of a --enable-gc flag we want to detect target_feature = "gc".

In the meantime of course wasm-bindgen might just introduce a switch.

@rustbot rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Dec 19, 2025
@daxpedda
Copy link
Contributor Author

daxpedda commented Dec 19, 2025

You can update this function to skip the feature on unsupported LLVM versions.

Done.

@alexcrichton
Copy link
Member

alexcrichton commented Dec 19, 2025

What would you think about landing this unstable and having a follow-up PR to switch it to stable? That'd help and get this in without merge conflicts and it can be separated from the FCP required for stabilization too. I'm not actually certain myself which team would need to sign off on this, T-lang or T-compiler, in terms of stabilization

@daxpedda
Copy link
Contributor Author

daxpedda commented Dec 19, 2025 •
edited
Loading

What would you think about landing this unstable and having a follow-up PR to switch it to stable? That'd help and get this in without merge conflicts and it can be separated from the FCP required for stabilization too. I'm not actually certain myself which team would need to sign off on this, T-lang or T-compiler, in terms of stabilization

Yeah, why not!

I will open a follow-up PR right away for stabilization so we can get that rolling in the meantime until LLVM 22 is released (a long way off probably).

@daxpedda daxpedda marked this pull request as ready for review December 19, 2025 19:23
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 19, 2025
@alexcrichton
Copy link
Member

alexcrichton commented Dec 19, 2025

@bors: r+

@bors
Copy link
Collaborator

bors commented Dec 19, 2025

📌 Commit 4ee01c4 has been approved by alexcrichton

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 19, 2025
@bors
Copy link
Collaborator

bors commented Dec 19, 2025

⌛ Testing commit 4ee01c4 with merge 9044e98...

@bors
Copy link
Collaborator

bors commented Dec 20, 2025

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 9044e98 to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 20, 2025
@bors bors merged commit 9044e98 into rust-lang:main Dec 20, 2025
12 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Dec 20, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Dec 20, 2025

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 806c2a3 (parent) -> 9044e98 (this PR)

Test differences

Show 3 test diffs

3 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 9044e98b66d074e7f88b1d4cea58bb0538f2eda6 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. pr-check-1: 1559.0s -> 2035.2s (+30.5%)
  2. aarch64-apple: 9361.6s -> 12113.6s (+29.4%)
  3. x86_64-gnu-miri: 4149.4s -> 5065.6s (+22.1%)
  4. x86_64-gnu-tools: 3258.4s -> 3793.7s (+16.4%)
  5. dist-x86_64-apple: 8153.6s -> 7035.5s (-13.7%)
  6. test-various: 6635.9s -> 7472.1s (+12.6%)
  7. x86_64-gnu-llvm-21-3: 6224.2s -> 6968.4s (+12.0%)
  8. x86_64-gnu-llvm-21-1: 4162.3s -> 4652.1s (+11.8%)
  9. x86_64-gnu-gcc: 3177.9s -> 3544.4s (+11.5%)
  10. i686-gnu-2: 5310.1s -> 5891.4s (+10.9%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

rust-timer commented Dec 20, 2025

Finished benchmarking commit (9044e98): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 6.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 6.9% [6.9%, 6.9%] 1
Regressions ❌
(secondary)		 - - 0
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 6.9% [6.9%, 6.9%] 1

Cycles

Results (primary -7.1%, secondary -4.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 - - 0
Improvements ✅
(primary)		 -7.1% [-15.9%, -2.6%] 5
Improvements ✅
(secondary)		 -4.8% [-8.4%, -2.4%] 6
All ❌✅ (primary) -7.1% [-15.9%, -2.6%] 5

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 477.964s -> 478.41s (0.09%)
Artifact size: 390.53 MiB -> 390.55 MiB (0.00%)

@daxpedda daxpedda mentioned this pull request Dec 20, 2025
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@alexcrichton alexcrichton

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

1.94.0

Development

Successfully merging this pull request may close these issues.

6 participants

@daxpedda @rust-log-analyzer @alexcrichton @bors @rust-timer @rustbot